クロスアカウントな AWS Transit Gateway で共有先アカウントからアタッチメントを削除したとき共有元アカウントではどうなるのか

クロスアカウントでTransit Gatewayを共有先のアカウントでアタッチメントするときは共有元のアカウントで承諾が必要です。共有アタッチメントの自動承諾を有効化していれば自動承諾されますが、無効化していれば以下の様に手動で承諾します。

共有先のアカウントでTransit Gatewayのアタッチメントが不要になり、アタッチメントを削除するとき共有元アカウントで承諾を得る必要があるのでしょうか？

以下のドキュメントを確認してもわかりませんでした。些細な疑問を解決するために試します。

• Transit gateway attachments to a VPC - Amazon Virtual Private Cloud

結果

• クロスアカウントで共有先アカウントからアタッチメントを削除すると、共有元アカウントの承諾は必要なく削除される。

やってみた

共有先アカウントから以下のTransit Gatewayアタッチメントを削除してみます。

共有元アカウントの画面

共有先アカウントのアタッチメント情報を確認できます。共有元アカウントにもアタッチメントしているため、2つアタッチメント情報が表示されています。

共有先アカウントの画面

共有先アカウントへ切り替え、Transit Gateway アタッチメントを削除します。

ステータスがDeletingになりました。削除がはじまっている気配。

共有元アカウントの画面

共有元アカウントへ戻り確認します。ステータスは同じくDeletingです。

そうこうしている間にDeletedになりました。

共有先アカウントの画面

共有先アカウントからも確認します。Deleted表示でアタッチメントは削除されました。

まとめ

クロスアカウントの共有先アカウントでアタッチメントするときは共有元アカウントで承諾を得る必要がある（自動承認無効の場合）が、アタッチメントを削除するときは共有先アカウントから一方的に削除できる。

おわりに

以下のリンクの様なPrivateLinkを集約するShared VPCを構築している場合ですと、Shared VPCの管理は情報システム部門で行い、システムが稼働するサビース提供用のVPCはアプリケーションチームの様に管理主管が分かれていることもあります。自動承認が無効な場合、Transit GatewayをアタッチメントするときはShared VPCの管理者に依頼し承諾作業を行ってもらいます。サービス提供用のVPCを管理するチームがアタッチメントを削除するとShared VPCの管理者の知らないうちにTransit Gatewayへの通信を切ることができます。Transit Gateway経由の通信は止まりサービス提供に影響でるかもしれません。今度は復旧したくてもShared VPC管理者の承諾を得ないと再アタッチメント（アタッチメントの新規作成）できないので復旧に時間がかかるかもしれません。アタッチメントの操作は慎重に。